home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Dr. Windows 3
/
dr win3.zip
/
dr win3
/
PROGRAMR
/
ASM32PM.ZIP
/
PMODE.DOC
< prev
next >
Wrap
Text File
|
1993-06-07
|
48KB
|
925 lines
Warning:
This document is intended for the experienced programmer with knowledge of
a good deal of assembly and the 386. If you are not one such person, the text
that follows will be very confusing to you. Read on if you wish... You have
been warned.
------------------------------------------------------------------------------
Some crap:
This is the doc for PMODE v1.29a. I am not going to rewrite it just for
version 2.1232 since almost all of this doc applies perfectly. There are a few
changes from PMODE 1.29a to 2.1232 however. They follow at the end of this
doc.
This code, as well as this doc (damn I hate writing dox), were written up
by Tran (a.k.a. Thomas Pytel) of Renaissance. It is intended for all those of
you out there who would like to code in protected mode, but keep running up
against obstacles. If you want to use this thing as it is though, you will
have to code in 100% ASM. But hey, that's no problem. I do it all the time. I
did write this thing for myself. So if you have a problem with it, tough. You
have a few options. You can use it as it is, and code in all ASM (not a
terribly difficult feat). You can examine the code, and use what you learn to
code up your own protected mode system, one that you can maybe throw into a
nice high level language maybe. Or you can just ignore this code and this doc.
------------------------------------------------------------------------------
Intro:
Ah... many are the joys and woes of this chip we all know as the 386. The
486 - bah, just a 386 with a cache. The 586 - hahaha, two 486s with double the
cache. But the wonderful 386 architecture. That finally gives us our needed
flat memory. Not to mention the paging (not a personal favorite, but VERY
useful). It's been around here for a while now, but it hasn't been used very
much. I'm assuming you know all the problems associated with sharing the
386 protected mode amongst different programs. So I'll just go on to tell ya
about two methods of doing this, VCPI and DPMI.
In the beginning (or at least a long time ago). There was the EMS and the
XMS. Two pathetic attempts by the hopelessly crippled (design-wise) 8086s and
286s. EMS and XMS were fine for accessing small chunks of a larger address
space at a time. These methods were usually very slow. As for XMS, the 286
actually had to copy memory every time it was requested. And hardware EMS
resided on the slow system bus (well, not that much slower compared to the
speed of those machines). With the introduction of the 386, and soon the
memory managers, things changed. EMS and XMS could now be handled with the
on-chip paging mechanism. Which was faster than the memory copy method, and
even the hardware EMS. But for this task, the memory managers had to run the
system in V86 mode. Forsaking all other programs which would want to take
control of the 386 protected mode.
Thus was devised VCPI. A method of allowing programs running in the V86
system to switch to protected mode. After switching to protected mode, those
programs would have total control of the system. Running at a privilege level
of 0. They could communicate with the other protected mode program, the VCPI
server, through a common memory address space starting with the first megabyte
of memory. VCPI was a superset of the EMS standard, and was implemented in
virtually all memory managers and 386 extenders. But VCPI was woefully
inadequate for the multitaskers that were soon to follow.
Then there came forth the DPMI standard. Born from the window, it is the
epitome of total lameness. Many are the unknowing peons who run the window.
And many are the lamer who do not know the purpose of our favorite key
combination, the CTRL+ALT+DEL. A wondrous function of that eternal TSR called
the BIOS. Many a fool activate it whilst on a local BBS, erroneously believing
they will get free downloads. But I digress, we were all lame at one time or
another. This standard of the DPMI was different from those of antiquity.
This foul interface was designed with total control in mind. Total control
by the evil host whose lameness was imposed upon all those running beneath it.
At a lowly CPL3, this loathsome beast's clients are truly at a disadvantage.
Their INs and OUTs under the thorough scrutiny of the master. Forced to
grovel for precious memory. Not even their own instructions are sacred. For
the fiend which is DPMI, patiently waits, and watches. Ready to tear the
precious life from the pitiable client at the slightest sign of the forbidden
CLI. Then the monster does its deeds, toggling an illusion of that which was
once real. This virtual flag of interrupts ensures the depraved host total
domination. So easy to hate it is this beast. But yet... In the name of
multiple tasking, and system integrity. The DPMI continues to gain ground.
(Well sure, if ya want those things. But where is your adventure... Your
spirit... Have you totally forgotten what a good crash feels like???)
These days, VCPI and DPMI permeate the world of 386 software. From memory
managers, to Windows and OS/2. If something is protected, its using one of
these. VCPI though, is on its way out. Being replaced by DPMI. And if you want
to code protected mode... Unless you force upon the user a clean boot, you
have to support one of these two standards.
------------------------------------------------------------------------------
So what you got here:
Having coded raw flat protected mode, I am hooked. I shall not revert to
real mode limitations. My previous protected mode system 'START32' was very
intolerant of crap like VCPI and DPMI and EMS and XMS and everything else. It
required a clean boot to function. But hey, for that I got pure wonderful
flat protected mode. Unfortunately, the masses did not share my sentiment.
And they whined about rebooting. Pitiful as they were, I have heard their
cries. And I understand. The culmination is the code before you (or rather in
the other file, PMODE.ASM). This is basically the same pure beautiful flat
protected mode system as my old START32 system, except that it will run under
VCPI and DPMI and XMS (albeit a little slower).
------------------------------------------------------------------------------
What it thinks it does:
The point of this protected mode header thingy is to provide a simple, flat
mode environment for easy assembly coding. PMODE will take care of detecting
a 386, the type of system (raw,XMS,VCPI,or DPMI) and making sure there is
enough memory, both low and high. The protected mode code runs in one big
segment, the size of which is infinite (or 4GB, whichever is larger). You can
call real mode interrupts of far routines from your pmode code. And those
in turn can call back to protected mode. And on and on like this to the limits
of the stack. Once in pmode, all normal IRQs are still active and are by
default, redirected to their real mode handlers. You can intercept these
IRQs for your own use, then pass them on to the real mode handlers or not.
This system was coded with speed in mind. It is meant for stuff like games,
demos (as in the ones with cool muzik and grafix), or stuff that needs a lot
of memory. What you should not attempt from this system, is going TSR, or
executing DOS programs. This system runs absolutely perfectly for what it was
meant for in raw and XMS. There are some minor problems under VCPI and DPMI
though, and i'll list them later. But right now...
------------------------------------------------------------------------------
First of all, the structure:
In PMODE.ASM, there are three segments. They are as follows:
) CODE16 - A 16bit segment that holds all the real mode and 16bit protected
mode init and exit code. I'm not sure (I've forgotten by now), but
you should probably leave it as the first segment of the EXE.
) CODE32 - The huge 32bit segment. You can throw in as much code as will fit
in low memory (no 64k fixup overflows). If you need more code
space, you're gonna have to load it into extended